-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move JDServer
lib code out of main.rs
#1095
Move JDServer
lib code out of main.rs
#1095
Conversation
9de3000
to
5f5c319
Compare
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
🚨 3 ALERTS: Threshold Boundary Limits exceeded!
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you intend to omit the Cargo.toml
change to specify a [[bin]]
value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Given the interaction with bitcoin core, would it be helpful to use this crate: https://github.com/rust-bitcoin/rust-bitcoincore-rpc
Or perhaps this would need to be updated for compatibility with @Sjors branch for the TP changes?
roles/jd-server/src/lib/core.rs
Outdated
let mut last_empty_mempool_warning = | ||
std::time::Instant::now().sub(std::time::Duration::from_secs(60)); | ||
|
||
// TODO if the jd-server is launched with core_rpc_url empty, the following flow is never |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should migrate this to a GH issue.
roles/jd-server/src/lib/core.rs
Outdated
Ok(_) => (), | ||
Err(err) => { | ||
// TODO | ||
// here there should be a better error management |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not it's own issue but perhaps an overarching issue for tracking better error handling across the code base? Seems like this could be part of the refactoring documentation/story.
cc: @plebhash @pavlenex @rrybarczyk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will need to happen as part of a different PR really. Its good that we have more visibility now about the technical debt in the code though
roles/jd-server/src/lib/core.rs
Outdated
} | ||
} | ||
_ => { | ||
// TODO here there should be a better error managmenet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strong indications that there is a need for a JDS specific error handling review. 😅
@@ -108,163 +103,5 @@ async fn main() { | |||
} | |||
}; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be helpful to keep this sort of daemon awareness logging.
info!("Jds INITIALIZING with config: {:?}", &args.config_path); |
roles/jd-server/src/main.rs
Outdated
} | ||
} | ||
} | ||
lib::core::JDServer::new(config).start().await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need associated import.
lib::core::JDServer::new(config).start().await; | |
JDServer::new(config).start().await; |
@marathon-gary wrote:
My branch does not change RPC methods, so that crate should not be impacted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK. I believe some of the error cases are no longer being triggered. If possible, could you remove those and resolve the other warnings as well.
Warning logs JDS
warning: field `tx` is never read
--> jd-server/src/lib/mempool/mod.rs:15:9
|
13 | pub struct TransactionWithHash {
| ------------------- field in this struct
14 | pub id: Txid,
15 | pub tx: Option,
| ^^
|
= note: `TransactionWithHash` has derived impls for the traits `Debug` and `Clone`, but these are intentionally ignored during dead code analysis
= note: `#[warn(dead_code)]` on by default
warning: field 0
is never read
--> jd-server/src/lib/mempool/error.rs:9:9
|
9 | Rpc(RpcError),
| --- ^^^^^^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
9 | Rpc(()),
| ~~
warning: field 0
is never read
--> jd-server/src/lib/mempool/error.rs:10:16
|
10 | PoisonLock(String),
| ---------- ^^^^^^
| |
| field in this variant
|
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
|
10 | PoisonLock(()),
| ~~
|
I hope its visible now. Thanks for pointing it out. |
5f5c319
to
5b0615a
Compare
Could you please explain how did you conduct the tests so I can try to replicate it? |
Not sure I wanna do this as part of this PR tbh |
@jbesraa Run all the roles in the following order: Pool, JDS, JDC, and Translator. Once they are in sync, terminate them using |
I think the changes here are reasonable as a requirement for the new Integration Tests framework. The same applies to all PRs tracked under #1093 If you closely look at the diff, you'll see it's mostly shuffling things around without deep architectural changes. It simply declares a new but I do understand where @rrybarczyk is coming from, and overall I agree we should be very conservative and limit the scope of changes to the I wrote a comment on a similar spirit on another, where (different to here) I believe we are getting a bit out of scope: #1115 (comment) |
I've seen this behavior before... I usually work around it by doing a indeed it's quite annoying, but this is just technical debt that unfortunately fall out of scope for this PR |
@marathon-gary I agree this is a desirable change, but we should keep in mind that this PR is simply introducing some necessary restructuring as a prerequisite for #1120 overall, there is technical debt all over the place (e.g.: todos, suboptimal error handling, suboptimal architecture), but we should resist the urge of trying to fix all of them now just because reviewing this PR made us aware of them |
5b0615a
to
5c5b0e1
Compare
bb58ced
to
9199cd5
Compare
9199cd5
to
cb979df
Compare
Move code outside of the `main.rs` to `lib/mod.rs` file to make `JDServer` accessible through other enviornements.
cb979df
to
006b838
Compare
part of #1093